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DETAILED ACTION 



Claim Rejections - 35 USC § 102 

1 . The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 



2, Claims 16, 18, 30, 33. 44, 46, and 52 are rejected under 35 U.S.C. 102(e) as 
being disclosed by Pardo (U.S. Pat. No. 6,266,539) (Telephone Docking Station for 
Personal Digital Assistant). 



2.1 Regarding claim 16, Pardo discloses a PDA, comprising: 

a memory for storing a list of phone features and phone policies therein 

(Abstract; Figs. 7, 8, 12; col. 9, lines 2 - 20); and 

software stored in the memory (col. 5, lines 12 - 18) for allowing a user to select 

and program user's personal phone features and phone policies within the PDA from 

the stored list of phone features and phone policies (Abstract; Figs. 7, 8, 12; col. 7, lines 

60 - 67; col. 9, lines 2 - 20). 
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2.2 Per claim 1 8, Pardo teaches that said software Includes a feature/policy 
application program (API), said feature/policy API being used to interface the PDA with 
phone features and phone policies of the user (col. 7, lines 60 - 67 "TAPI (Telephony 
Application Programming Interface)"). 

2.3 Regarding claims 30, 33, 44, 46, and 52, the rejection of claims 16 and 18 
(paragraphs 2.1 and 2.2 above) under 35 USC 102(e) applies fully. 

3. Claims 1 6 - 1 8, 30 - 33, 44 - 46, and 52 are rejected under 35 U.S.C. 1 02(e) as 
being anticipated by Kikinis et al. (U.S. Pat. No. 5,799,068) (Smart Phone Integration 
with Computer Systems). 

3. 1 Per claim 1 6, Kikinis teaches a PDA, comprising: 

a memory for storing arranged infomnation including phone features and phone 
policies (Fig. 13; col. 17, lines 30 - 35 "the user interface will query a user for input of 
one or more passwords, after successful entry of which the host will pass the input to 
microcontroller 101 1 for comparison with the serial number and perhaps other codes 
accessed fomn the EEPROM 1031 in the bootstrap of the microPDA"; col. 8, lines 63 - 
67); and 

software stored in the memory (Fig. 13; col. 17, lines 30 - 35; col. 8, lines 63 - 
67) for allowing a user to select and program the user's personal phone features and 
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phone policies within the PDA from the stored list of phone features and phone policies, 
at least one of the user's personal phone policies being used to implement at least one 
of the user's personal phone features in a telecommunication system (col. 10, lines 39 - 
47; col. 12, lines 39 - 47 "Memory 1013 is preferably a nonvolatile device from 1 to 2 
megabytes in this embodiment, and both control routines for applications and data 
files are stored in this memory."). 

3.2 Regarding claim 17, Kikinis discloses a PDA, comprising: 

a memory for storing a list of phone features and phone policies therein (Figs. 9, 
13, item 1013; col. 12, lines 39-47; col. 10, lines 39-47; col. 12, lines 39-47 
"Memory 1013 is preferably a nonvolatile device from 1 to 2 megabytes in this 
embodiment, and both control routines for applications and data files are stored in 
this memory.").); and 

software stored in the memory (Fig. 13, item 1013; col. 17, lines 30 - 35; col. 8, 
lines 63 - 67) for allowing a user to program the user's personal phone features and 
phone policies within the PDA using the stored list of phone features and phone policies 
(col. 1 2, lines 39 - 47; col. 1 0, lines 39 - 47) wherein 

the memory includes prestored identification data for the user, and said PDA 
further includes a security unit for verifying the identity of the user based on the 
prestored identification data (Fig. 13; col. 17, lines 30 - 35 "the user interface will query 
a user for input of one or more passwords, after successful entry of which the host will 
pass the input to microcontroller 101 1 for comparison with the serial number and 
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perhaps other codes accessed form the EEPROM 1031 in the bootstrap of the 
microPDA"; col. 8, lines 63 - 67). 

3.3 Per claim 18, Kikinis teaches the PDA as defined in claim 16 wherein said 
software includes a feature/policy application progranri interface (API), said 
feature/policy API being used to interface the PDA with phone features and phone 
policies of the user (col. 6, lines 23 - 28 '"PC workstation 21 in this embodiment has a 
Telephony Application Programming Interface (TAPI) that coordinates Windows 
applications running on the PC will call functions on the Smart Phone."). 

3.4 Per claims 30 - 33, 44 - 46, and 52, the rejection of claims 16-18 under 35 
use 102(e) (paragraphs 3.1 - 3.3 above) applies fully. 

4. Claims 16, 18, 30, 33, 44, 46, and 52 are rejected under 35 U.S.C. 102(e) as 
being anticipated by Graham (U.S. Provisional Pat. No. 60/098,187). 

4.1 Per claim 16, Graham teaches a PDA, comprising: 

a memory for storing arranged information including phone features and phone 
policies (Fig. 6; p. 5, paragraph 1; p. 1, paragraphs 1, 5); and 

software stored in the memory (Fig. 6; p. 5, paragraph 1 ) for allowing a user to 
select and program the user's personal phone features and phone policies within the 
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PDA from the stored list of phone features and phone policies, at least one of the user's 
personal phone policies being used to implement at least one of the user's personal 
phone features in a telecommunication system (Fig. 6; p. 5. paragraph 1; p. 1, 
paragraphs 1 , 5). 

Certain aspects of this user interface and architecture can be added to any Windows device wishing to 
become more telephony enhanced - from a user perspective. For example, a Palm-sized PC can be 
equipped with the Call Slip interface (a single call slip) that interacts with a PBX phone and the PC 

to show call information and control features on a docked device - enhancing the capabilities of the 
phone while tying into the network capabilities of the PC. Similarly, the same Ul could be added to a sub- 
notebook device, or even in a somewhat adapted form, to a cellular phone. Across all of them would be a 
common architecture for delivering services and a similar user experience, if not identical due to 
physical constraints, (p. 5, paragraph 1). 

4.2 Per claim 18, Graham teaches the PDA as defined in claim 16 wherein said 
software includes a feature/policy application program interface (API), said 
feature/policy API being used to interface the PDA with phone features and phone 
policies of the user (Fig. 6 "TAPI and Hermes Telephony Extensions"; p. 4, paragraph 1 
"TAPI"). 

4.3 Regarding claims 30, 33, 44, 46, and 52, the previous rejection under 35 USC 
1 02(e) (paragraphs 4. 1-4.2) applies fully. 



Claim Rejections - 35 USC § 103 
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5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

6. Claims 1 - 3, 5 - 1 1 , 19 - 24, 34 - 38, 47, and 48 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Graham (U.S. Provisional Pat. No. 60/098,187) in 
view of Mattaway (U.S. Pat. No. 6.009,469) (Graphic User Interface for Internet 
Telephony Application). 

6.1 Regarding claim 1, Graham discloses a method of operating a PDA, comprising 
the steps of: 

arranging information within the PDA to correspond to at least one of first and 
second data sets, the first data set including phone features of a user, at least on of the 
phone features being set up in a telecommunication system for the user, the second 
data set including phone policies {phone numbers and phone line numbers) of the user, 
at least one of the phone policies being used for implementing the at least one of the 
phone features (Fig. 6 "Settings" "Third Party Application" "Address Book"); 

"The Hermes Call Slip Architecture provides a means for software developers, including Microsoft, OEMs, 
Telcos and other 3"^ parties to easily add to and extend the capabilities of a telephone device with a 
graphical user interface. The user-interface abstracts and exposes line nrianagement and call control 
features in a single user interface elennent that Is state-smart so it can present different options when the 
telephone is in different states, such as ringing, receiving Caller ID information, Caller ID on Call Waiting, 
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etc. Provides users with a standardized graphical interface to common line management and call 
control features such as Caller ID. Caller ID/Call Waiting, call duration, etc. as well as providing an 
architecture for developing and delivering new line or call control features as part of the standardized 
experience. New features fit in visually and functionally." (p. 1 , paragraph 1). 

Certain aspects of this user interface and architecture can be added to any Windows device wishing to 
become more telephony enhanced - from a user perspective. For example, a Palm-sized PC can be 
equipped with the Call Slip interface (a single call slip) that interacts with a PBX phone and the PC 

to show call information and control features on a docked device - enhancing the capabilities of the 
phone while tying into the network capabilities of the PC. Similarly, the same Ul could be added to a sub- 
notebook device, or even in a somewhat adapted form, to a cellular phone. Across all of them would be a 
common architecture for delivering services and a similar user experience, if not identical due to 
physical constraints, (p. 5, paragraph 1). 

downloading at least a portion of the arranged information to a phone device, the 
arranged information including the at least one of the features and the at least one of 
the policies (p. 1 , paragraph 1 (see above)). 

For example, a Palm-sized PC can be equipped with the Call Slip interface (a single call slip) that 
interacts with a PBX phone and the PC to show call information and control features on a docked 
device - enhancing the capabilities of the phone while tying into the network capabilities of the PC. (p. 

5, paragraph 1) 

However, Graham does not explicitly disclose downloading at least a portion of the 
arranged information to an Internet Protocol (IP) phone device. 
Graham does disclose that "this architectural flexibility extends beyond architectural 
nuances (differences in central office switching hardware and configurations) to allowing 
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us to support different underlying network infrastructures. For example PSTN vs. 
ISDN, or even moving to full IP solution. In each case, we would want similar or the 
same presentation to the user for a specific feature, but would be able to write different 
underlying drivers to implement those features appropriate to the specific network." (p. 
1 , paragraph 4). 

Mattaway discloses control information downloaded to an IP phone device (Fig. 1, item 
12; col. 5, lines 49 - 51 "The input device 18 may alternatively include connections to 
other computer systems to receive the input commands and data therefrom."). 
It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the IP phone device of Mattaway in Graham because Graham explicitly 
states supporting "different underlying network infrastructures" and that a "full IP 
solution" can be implemented. 

6.2 Per claim 2, Graham teaches that said arranging step includes the steps of: 
storing a list of predetermined phone features in the PDA (Fig. 6 "Settings" "Third 

Party Application" "Address Book"; p. 9, paragraph 1 "Telephone Features - The 
Hermes Phone Manager"); and 

selecting, in the PDA, certain phone features from the list of predetermined 
phone features to arrange the information (p. 5, paragraph 1; p. 1, paragraph 5). 

6.3 Regarding claim 3, Graham discloses that said operating steps includes the step 
of: 
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synchronizing the PDA with the IP phone device (p. 5, paragraph 1 "Palm-sized 
PC ... interacts with a PBX phone ..."). 

6.4 Regarding claim 5, Graham discloses that said operating step includes the step 
of: 

receiving and initiating calls through the IP phone device according to the 
arranged information from said arranging step (Fig. 6; p. 5, paragraph 1; p. 1, 
paragraphs 1,5). 

6.5 Per claim 6, Graham teaches the step: 

modifying the arranged information of said arranging step (Fig. 6; p. 5, paragraph 
1; p. 1, paragraphs 1, 5). 

6.6 Regarding claim 7, Graham discloses that in said arranging step, the PDA 
includes a phone application program interface (API) for interfacing the PDA with phone 
functionality of the IP phone device (Fig. 6 "TAP! and Hermes Telephony Extensions"; 
p. 4, paragraph 1 "TAPI"). 

6.7 Per claim 8, Graham teaches that in said arranging step, the PDA includes a 
feature/policy application program interface (API) for interfacing the PDA with the phone 
features and phone policies of the user (Fig. 6 "TAPI and Hennes Telephony 
Extensions"; p. 4, paragraph 1 "TAPI"). 
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6.8 Regarding claim 9, Graham discloses the method as defined in claim 1 further 

comprising the step of: 

connecting the PDA to a PBX via the phone device (p. 5, paragraph 1). 
a Palm-sized PC can be equipped with the Call Slip interface (a single call slip) that interacts with 
a PBX phone and the PC to show call information and control features on a docked device - enhancing 
the capabilities of the phone while tying into the network capabilities of the PC. 

6.9 Regarding claim 10. Graham discloses a method of operating a PDA. comprising 
the steps of: 

arranging information within the PDA to correspond to at least one of a first and 
second data sets, the first data set including phone features of a user, at least one of 
the phone features being set up in a telecommunication system for a particular phone 
number, the second data set including phone policies of the user, at least one of the 
phone policies being used for implementing the at least one of the phone features (Fig. 
6; p. 5, paragraph 1; p. 1, paragraph 1; p. 9, paragraph 1); and 

transferring the arranged information to a PBX (Fig. 6; p. 1, paragraph 1; p. 4, 
paragraph 2; p. 5, paragraph 1). 

Certain aspects of this user Interface and architecture can be added to any Windows device wishing to 
become more telephony enhanced - from a user perspective. For example, a Palm-sized PC can be 
equipped with the Call Slip interface (a single call slip) that interacts with a PBX phone and the PC 
to show call information and control features on a docked device - enhancing the capabilities of the 
phone while tying into the network capabilities of the PC. Similarly, the same Ul could be added to a sub- 
notebook device, or even in a somewhat adapted form, to a cellular phone. Across all of them would be a 
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common architecture for delivering services and a similar user experience, if not identical due to 
physical constraints, (p. 5, paragraph 1). 

However, Graham does not explicitly disclose that the PBX is an IP-PBX (Internet 
Protocol-Public Branch Exchange). 

Mattaway discloses an equivalent to the IP-PBX (Fig. 1 , items 24, 26; col. 12, lines 23 - 
28). 

Examiner notes that an "IP-PBX Is a known switch system that controls phone 
operations and associated devices, with an application program interface (API) which 
allows the functionality and settings of the IP-PBX to be accessible from the Internet 
100 by devices including the PDA 10, the IP phone 40, etc." (see p. 4, line 33 through p. 
5, line 1 of the specification). 

Graham does disclose that "this architectural flexibility extends beyond architectural 
nuances (differences in central office switching hardware and configurations) to allowing 
us to support different underlying network infrastructures. For example PSTN vs. 
ISDN, or even moving to full IP solution. In each case, we would want similar or the 
same presentation to the user for a specific feature, but would be able to write different 
underlying drivers to implement those features appropriate to the specific network." (p. 
1 , paragraph 4). 

The "full IP solution" would certainly include the known IP-PBX as disclosed in 
specification of the present Application. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the switching device (IP-PBX) of Mattaway in Graham because Graham 
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explicitly states supporting "different underlying network infrastructures" and that a "full 
IP solution" can be implemented. 

6.10 Regarding claim 1 1 , Graham discloses that said transferring step includes the 
step of connecting the PDA to the PBX through the Internet (Fig. 6; p. 5, paragraph 1 ; p. 
1, paragraphs 1,5). 

The reasoning for implementing a PBX instead of an IP-PBX is given above in the 
rejection of claim 10. 

6.1 1 Per claims 19 - 24, 34 - 38, 47, and 48, the rejection of claims 1 - 3, 5 - 1 1 
(paragraphs 6.1-6.10 above) applies fully. 

7. Claims 4. 12, 25, 26, 39, and 40 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Graham (U.S. Provisional Pat. No. 60/098,187) in view of Mattaway 
(U.S. Pat. No. 6,009,469) and Kikinis et al. (U.S. Pat. No. 5,799,068). 

7.1 Regarding claims 4 and 12, Graham teaches a method of operating a PDA, 
comprising the steps of:., 

arranging information with the PDA to correspond to at least a first and a second 
data set, the first data set including phone features of a user, the second data set 
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including phone policies of the user (Fig. 6; p. 5, paragraph 1; p. 1. paragraph 1; p. 9, 
paragraph 1 ); 

transferring the arranged information to a PBX (Fig. 6; p. 1. paragraph 1; p. 4, 
paragraph 2; p. 5, paragraph 1 ). 

Certain aspects of this user interface and architecture can be added to any Windows device wishing to 
become more telephony enhanced - from a user perspective. For example, a Palm-sized PC can be 
equipped with the Call Slip interface (a single call slip) that interacts with a PBX phone and the PC 

to show call information and control features on a docked device - enhancing the capabilities of the 
phone while tying into the network capabilities of the PC. Similarly, the same Ul could be added to a sub- 
notebook device, or even in a somewhat adapted form, to a cellular phone. Across all of them would be a 
common architecture for delivering services and a similar user experience, if not identical due to 
physical constraints, (p. 5, paragraph 1). 

However, Graham does not explicitly disclose that the PBX is an IP-PBX (Internet 
Protocol-Public Branch Exchange). 

Mattaway discloses an equivalent to the IP-PBX (Fig. 1 , items 24, 26; col. 12, lines 23 - 
28). 

Examiner notes that an "IP-PBX is a known switch system that controls phone 
operations and associated devices, with an application program interface (API) which 
allows the functionality and settings of the IP-PBX to be accessible from the Internet 
100 by devices including the PDA 10, the IP phone 40, etc." (see p. 4, line 33 through p. 
5, line 1 of the specification), 

Graham does disclose that "this architectural flexibility extends beyond architectural 
nuances (differences in central office switching hardware and configurations) to allowing 
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us to support different underlying networl^ infrastructures. For example PSTN vs. 
ISDN, or even moving to full IP solution. In each case, we would want similar or the 
same presentation to the user for a specific feature, but would be able to write different 
underlying drivers to implement those features appropriate to the specific network." (p. 
1, paragraph 4). 

The "full IP solution" would certainly include the "known IP-PBX" as disclosed in 
specification of the present Application. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the switching device (IP-PBX) of Mattaway in Graham because Graham 
explicitly states supporting "different underlying network infrastructures" and that a "full 
IP solution" can be implemented. 

In addition, Graham does not explicitly teach the steps of 

prestdring identification data of the user in the PDA; and 

verifying, before said arranging step, the identity of a current user of the PDA 

based on the prestored identification data. 

Graham does disclose "Multi-User Capability" wherein "the user can select a different 
user's message center by touching the user name field at the top of the screen. A 
menu of user names will appear. Touching a name on this menu will navigate to the 
selected user's message center." (p. 19, paragraph 5). 
Kikinis discloses the steps of: 
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prestoring identification data of the user in the PDA (Fig. 13; col. 17, lines 30 - 35 
"the user interface will query a user for input of one or more passwords, after successful 
entry of which the host will pass the input to microcontroller 101 1 for comparison with 
the serial number and perhaps other codes accessed form the EEPROM 1031 in the 
bootstrap of the microPDA"; col. 8, lines 63 - 67). 

verifying, before said arranging step, the identity of a current user of the PDA 
based on the prestored identification data (col. 17, lines 30 - 35; col. 8, lines 63 - 67). 
It would have been obvious to one of ordinary skill in the art at the time of the invention 
to implement the identification system of Kikinis in Graham because the users of the 
Graham system would want to secure their message center data that could possibly be 
viewed by other users. 

7.2 Per claims 25, 26, 39, and 40, the rejection of claims 4 and 12 under 35 USC 102 
(paragraph 7.1 above) applies fully. 

8. Claims 1 3 - 1 5, 27 - 29, 41 - 43, and 49 - 51 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Kikinis et al. (U.S. Pat. No. 5,799,068) in view of 
Graham (U.S. Provisional Pat. No. 60/098,187). 

8.1 Regarding claim 13, Kikinis discloses a method of operating a Personal Digital 
Assistant (PDA), comprising the steps of: 



Application/Control Number: 09/1 92,273 Page 1 7 

Art Unit: 2141 

storing at least first and second data sets within the PDA, the first data set 
including phone features of a plurality of user scenarios, the second data set including 
phone policies of the plurality of user scenar/os (col. 18, lines 1 -8; Fig. 13, item 1013; 
col. 1 2, lines 25 - 47; col. 21 , lines 5 - 25); 

Another useful feature in host/microPDA communication is a means for a user to select and compose a 
mix of executable program files for downloading to a microPDA, either replacing or supplementing those 
executable routines already resident. A user can have several different program lists for 
downloading as a batch, conveniently configuring the applicability of a microPDA among a wide 
variety of expected work environments (col. 18, lines 1 - 8). 

col. 12, lines 25 - 47 "Memory 1013 is preferably a nonvolatile device from 1 to 2 megabytes in this 
embodiment, and both control routines for applications and data files are stored in this memory." 

(col. 12, lines 25-47). 

displaying phone configurations in a telecommunication system based on said at 
least one of first and second data sets stored within the PDA (Figs. 9, 21; col. 32, lines 5 
-25), 

However, Kikinis does not explicitly disclose storage of phone features and/or phone 
policies for a plurality of users. 

Graham does disclose "Multi-User Capability" wherein "the user can select a different 
user's message center by touching the user name field at the top of the screen. A 
menu of user names will appear. Touching a name on this menu will navigate to the 
selected user's message center." (p. 19, paragraph 5). 
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It would have been obvious to one of ordinary skill In the art at the time of the invention 
to Implement the multi-user capability of Graham in the invention of Kikinis; because the 
downloading of executable program files yielding "several different program lists" on the 
microPDA of Kikinis would enable the invention of Kikinis to be used by multiple 
individuals or an administrator. 

8.2 Per claim 14, Kikinis teaches the method defined in claim 13 further comprising 
the steps of: 

prestoring identification data of a verifier within the PDA (Fig. 13; col. 17, lines 
30 - 35 "the user interface will query a user for input of one or more passwords, after 
successful entry of which the host will pass the input to microcontroller 101 1 for 
comparison with the serial number and perhaps other codes accessed form the 
EEPROM 1031 in the bootstrap of the microPDA"; col. 18, lines 63 - 67); and 

verifying the identity of a current verifier based on the prestored identification 
data (col. 17, lines 30 - 35; col. 18, lines 63 - 67). 

8.3 Regarding claim 15, Kikinis discloses the method as defined in claim 13 further 
comprising at least one of the following steps: 

deleting certain phone features and phone policies from the phone features and 
phone policies stored within the PDA (col. 19, lines 5-14 "demo copy of an 
application" "the software is transferable between a family of keyed microPDAs, or has 
the ability of 'unlock' only a limited number of times."); 
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modifying the phone features and phone policies stored within the PDA (col. 19. 
lines 5 - 14); and 

selecting certain phone features and phone policies from the phone features and 
phone policies stored within the PDA (Fig. 9; col. 10, lines 39 - 47). 

8.4 Per claims 27 - 29, 41 - 43. and 49 - 51 . the rejection of claims 13-15 under 
35 use 103 (paragraphs 8.1 - 8.3 above) applies fully. 

Response to Arguments 

9. Applicant's arguments filed 7/1 1/05 have been fully considered but they are not 
persuasive. 

With regard to independent claim 16, Applicant argues that Pardo does not suggest "at 
least one of the user's personal phone policies being used to implement at least one of 
the user's personal phone features in a telecommunication system." 
Examiner disagrees. 

The telecommunication system of Pardo includes the telephone docking station. 

With regard to independent claim 16, Applicant argues that the "serial number"; 
"perhaps other codes"; and "control routines for applications and data files" of Kikinis do 
not teach "phone features and policies." 
Examiner disagrees. 
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As seen in Figure 9. Kikinis discloses plug-in modules that represent "phone features 
and policies." 

With regard to independent claim 16, Applicant argues that Graham does not disclose 
"at least one of the user's personal phone policies being used to Implement at least one 
of the user's personal phone features in a telecommunication system ." 
Examiner disagrees. 

The telecommunication system of Graham includes the Palm-sized PC, PBX phone and 
PC. 

With regard to independent claim 1, Applicant argues that Mattaway fails to teach or 
suggest "downloading at least a portion of the arranged information to an internet 
protocol phone device." 
Examiner disagrees. 

As stated in the rejection of claim 1, Mattaway discloses control information downloaded 
to an IP phone device (Fig. 1, item 12; col. 5, lines 49 - 51 "The input device 18 may 
alternatively include connections to other computer systems to receive the input 
commands and data therefrom."). 

With regard to claims 4 and 12, Applicant argues that Graham does not teach 
"transferring the arranged information to an Internet Protocol-Public Branch Exchange." 
Examiner disagrees. 
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Graham states that a "palm-sized PC can be equipped with the Call Slip interface that 
interacts with a PBX phone and PC to show call information and control features on a 
docked device - enhancing the capabilities of the phone while tying in to the 
network capabilities of the PC. " (page 5, paragraph 1). 

With regard to claims 25 and 26, Applicant argues that Graham does not teach "at least 
one of the user's personal phone policies being used to implement at least one of the 
user's personal phone features in a telecommunication system ." 
Examiner disagrees. 

The telecommunication system of Graham includes the Palm-sized PC, PBX phone and 
PC. 

With regard to claim 13, Applicant argues that there is no motivation or suggestion to 
combine the teachings of Graham and Kikinis. 
Examiner disagrees. 

Graham discloses "Multi-User Capability" (p. 19, paragraph 5), which suggests the 
storage of phone features and phone policies for a plurality of users. 

Conclusion 

1 0. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 
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A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .1 36(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

1 1 . Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Kenneth R. Coulter whose telephone number is 571 
272-3879. The examiner can normally be reached on 5 4 9. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Rupal Dharia can be reached on 571 272-3880. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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